Repository navigation
Conversation
284km
left a comment
284km
left a comment
There was a problem hiding this comment.
Reviewed 8dfc245 against e45622a. No actionable findings.
The refresh preserves the complete timing inventory and uses the originating run's source/compiler/Ruby provenance. The estimates affect placement only; the workflow, limits, concurrency, and verdict handling are unchanged.
Validation:
- Downloaded
unittest-reportandunittest-planfrom completed successful run 42361097257. The new snapshot exactly matches its generated timings artifact except for the addedrun_url; all provenance fields agree with the report and source plan. - All 758 keys are unique and unchanged from the base, with finite positive durations. They exactly cover the source manifest and the inventory rediscovered from the pinned Ruby commit.
- Replanned with the production
unittest/ci.pyscheduler: all 758 files occur exactly once across eight shards, all weights match, and the recorded timing hash is correct. The old weights also reproduce the original shard assignments. - Independently replayed the observations: old shard totals are 707.950–1,383.483 s; refreshed totals are 959.771–960.594 s. Four-worker replay is 2,298.315 → 1,920.384 s, a 16.444% reduction, consistent with the README. This is a scheduling replay, not a new execution-time measurement.
- The source report confirms 8/8 shards, zero missing files/infrastructure errors, zero WALL_LIMIT files, 22 MEMORY_LIMIT files, and 166 incomplete or zero-test files, matching the documented qualifications.
python3 unittest/ci_check.py -v: 45 tests, OK, with five optional real-Ruby fixture tests skipped because their environment variables were unset.git diff --checkpassed. This PR's harness and planning checks have passed; runtime/reference/Linux jobs remain pending at review time.
No interpreter rebuild or full CRuby rerun was needed for this data-and-documentation change.
|
Thanks for independently checking all 758 timing values, provenance and the scheduling replay. No changes are needed for these positive findings. The replay remains explicitly an estimate rather than an end-to-end CI claim. I will mark this ready once the current run has collected every shard and the final report has no missing files or infrastructure errors. |
|
Final validation for The report still records 26 MEMORY_LIMIT files, 170 incomplete/zero-test files in total, and compatibility failures; no WALL_LIMIT files were recorded. Those runtime limitations remain visible and are being investigated separately. This PR changes scheduling estimates only, and its 16.4% result remains a replay estimate rather than a measured workflow speedup. Marking this PR ready. |
Runtime fixes changed the costs of the 758 CRuby test files, but CI still schedules them using the earlier snapshot. In the completed main run, the eight shards ranged from 708 to 1,384 seconds of supervised execution.
Refresh
unittest/timings.jsonfrom run 42361097257, preserving its source/compiler/Ruby provenance, and document the measured distribution. Replaying those same observations produces 960 seconds per shard and reduces the four-worker execution estimate from 2,298 to 1,920 seconds (16.4%). This is a scheduling replay, not a measured end-to-end speedup. File coverage, limits and concurrency are unchanged.Validation: all 758 files are assigned exactly once; the existing CI harness suite passed 45 tests (5 environment-dependent skips). The source report collected all eight shards without infrastructure errors. Its 22 memory-limited files and other compatibility failures remain explicitly reported.
Final PR validation: run 42366745969 passed all 29 jobs and collected 758 files from 8/8 shards without missing files or infrastructure errors. It records 26 memory-limited files and 170 incomplete/zero-test files overall; those runtime limitations remain separate from this scheduling-only change.